Skip to content

feat(release): guard template lockfile version + registry parity - #627

Open
atilafassina wants to merge 1 commit into
mainfrom
template-lock-parity-guard
Open

atilafassina wants to merge 1 commit into
mainfrom
template-lock-parity-guard

Conversation

@atilafassina

Copy link
Copy Markdown
Contributor

What

Follow-up to #626 (the Fix). That PR made the release-publish sites regenerate both template lockfiles; this adds the Guard so a stale or internal-registry template lockfile can never silently ship again — the gap that let the original regression reach a release.

The template is pnpm-first and ships both package-lock.json and pnpm-lock.yaml; databricks apps init keeps the chosen PM's lock and drops the other, so either lock can be the one a user installs from. These guards assert both are correct before anything is published.

Changes

  • tools/check-template-lock-versions.ts (new) — parity verifier. Reads the resolved @databricks/appkit / @databricks/appkit-ui version from each lock, dispatching by format: npm packages["node_modules/<pkg>"].version; pnpm importers["."].dependencies[<pkg>].version (peer-dependency suffix stripped). Pure verifyLockVersions(lockPaths, expected) function plus a CLI. Unit tests cover both formats, both packages, and the exact stale-pnpm-lock regression.
  • tools/check-template-deps.ts — asserts lock↔package.json version parity, so drift fails this repo's PR CI (already wired at ci.yml).
  • tools/publish-template-tag.ts — before commit, aborts the release if (a) the regenerated locks disagree with the published version, or (b) either committed lock references a non-public registry (validate-only, fail-closed — no rewrite, since a JFrog URL on the public-npm tag path means the environment is wrong).

Why the registry check is validate-only here

Unlike the artifact-zip path (which installs under JFrog and rewrites back to public npm), the git-tag path installs from public npm. A non-public URL there is an environment fault that should abort loudly, not be silently rewritten.

Testing

  • pnpm check, pnpm -r typecheck, pnpm test all green (5370 passed, +9 new).
  • Verified the CLI live: passes against the current committed template locks; catches a planted version mismatch with clear per-lock messages.

This pull request and its description were written by Isaac.

Add a fail-closed guard so a stale or internal-registry template lockfile can
never ship — the gap that let the Phase-1 regression reach a release.

- check-template-lock-versions.ts: new verifier reading the resolved
  @databricks/appkit(-ui) version from both lock formats (npm packages[] entry;
  pnpm importers["."].dependencies, peer suffix stripped). Pure function plus a
  CLI. Unit tests cover both formats, both packages, and the stale-pnpm-lock
  regression.
- check-template-deps.ts: assert lock<->package.json version parity, so drift
  fails this repo's PR CI.
- publish-template-tag.ts: before commit, abort the release if the regenerated
  locks disagree with the version, or if either lock references a non-public
  registry (validate-only, no rewrite).

Co-authored-by: Isaac <no-reply@databricks.com>
Signed-off-by: Atila Fassina <atila@fassina.eu>
@github-actions

github-actions Bot commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

🤖 AppKit PR bot

🔬 Run evals

Start an eval for this PR from the evals-monitor app: Go to Evals Monitor →

📦 Try this PR's app template

Scaffolds a new app from this PR's SDK build. Run it in any folder (requires the GitHub CLI — gh auth login — and the Databricks CLI):

gh run download 37032617265 -R databricks/appkit -n appkit-template-0.82.0-pr.0cf5fd0-template-lock-parity-guard-627 -D appkit-pr-627 \
  && unzip -o "appkit-pr-627/appkit-template-0.82.0-pr.0cf5fd0-template-lock-parity-guard-627.zip" -d "appkit-pr-627" \
  && databricks apps init --template "appkit-pr-627"

The template pins @databricks/appkit and @databricks/appkit-ui to tarballs built from this branch, so the scaffolded app runs against this PR's code.

@atilafassina
atilafassina marked this pull request as ready for review October 6, 2026 15:12
@atilafassina
atilafassina requested a review from a team as a code owner October 6, 2026 15:12
@atilafassina
atilafassina requested review from MarioCadenas and pkosiec and a balanced review from Copilot October 6, 2026 15:12

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟡 Changes recommended

The release registry check currently permits local file: resolutions in committed lockfiles.

Review effort: Balanced
Findings: 1 High severity

Open (1)
What changed in this PR

Adds release safeguards to keep both template lockfiles aligned with SDK versions and public npm.

Changes:

  • Adds npm/pnpm lock-version verification with tests.
  • Integrates parity checks into CI and template publishing.
  • Adds pre-tag registry validation.
File Description
tools/​check-template-lock-versions.ts Implements lock-version verification.
tools/​check-template-lock-versions.test.ts Tests both lock formats and stale versions.
tools/​check-template-deps.ts Enforces lock/package parity in CI.
tools/​publish-template-tag.ts Adds pre-publish version and registry guards.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +137 to +143
run("pnpm", [
"exec",
"tsx",
"tools/check-template-lock-registry.ts",
lock,
"--allow-file",
]) !== 0

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants